I would prefer to have the bugfix go in 1.6, but as a last resort, this is an alternative to #18480 to at least keep the bugfix for #17393 in devel.
refs #18480 (comment)

much better than reverting the commits as was attempted in #18480, likewise with other reverts that are currently pending and other similar reverts that were made in 1.5.

• People targeting stable cannot complain anymore and have more time to migrate to new behavior (they'll know what lines of code need attention thanks to warnings we can add for each use of deprecated behavior)
• they'll also be able to opt-in to new behavior in a targeted way (1 feature at a time)
• people targeting devel get their bugfixes and saner, more consistent behavior, by default, without having to wait for next major bump.

this will then work in devel using new semantics, and work on 1.6 using old semantics, but still be over-rideable with either cmdline flag -u:nimLegacyHomeDir or a flag in your user config -u:nimLegacyHomeDir. Code can query which behavior is used using when defined(nimLegacyHomeDir).

if 1.8 is released in future (instead of 2.0), the question can be asked again at that time whether 1.8 wants the old or new behavior for each individual breaking change, and the logic can be extended accordingly with a 1 line change, all in 1 place ($nim/config/config.nims).

This isn't a perfect solution but it's a better solution than removing bugfixes or cementing bad design decisions, and it allows users that want those bug fixes and the better design to get it as default without waiting for the next major bump (2.0, or when 2.0 has a bug, 3.0). Instead, they can at least get it in devel, and eventually get it in some stable branch (whether 1.8 or 2.0).

The key part is that in devel, the sane behavior should be the default, not an opt-in flag that requires adding a flag. That is the only way to prevent balkanization in the long term.

In future work, a localizable approach can be implemented, such that a project A can opt-in new semantics in a stable branch while the rest uses the default semantic for that branch; it's tricky but doable.

future work

• generalize this to other nimLegacyX flags as needed, and reconsider certain PRs that were reverted to use this approach instead
• add warning for usages of deprecated behaviors to ease client code migration to new behavior; specific deprecations: --warning:deprecated:foo:on|off timotheecour/Nim#403 would make these warnings more useful as you'd be able to silence individual deprecations insetead of all or nothing as is currently the case with --warning:deprecation:on|off (EDIT: see add {.migrated(ident, msg):... .} to issue callsite migration warnings for changed APIs #18513)
• implement a localizable approach (harder, but doable)